This Page Is Inserted by LFW Operations 
and is not a part of the Official Record 

BEST AVAILABLE IMAGES 



Defective linages within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS . 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 



• GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



THIS PAGE BLANK 0*h«. 



(19) 



Europaisches Patentamt 
European Patent Office 
Office europeen d s brev ts 




(12) 



(1D EP 0 838 771 A2 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 


(51) mtci e : G06F 17/30, G01C 21/20 


29.04.1998 Bulletin 1998/18 


(21) Application number: 97308523.6 




(22) Date of filing: 24.10.1997 




(84) Designated Contracting States: 


• Natesan, Senthil K. 


AT BE CH DE DK ES Fl FR GB GR IE IT LI LU MC 


Carol Stream, Illinois 60188 (US) 


NL PT SE 


• Killey, Grant S. 


Designated Extension States: 


Westmont, Illinois 60559 (US) 


AL LT LV RO SI 


• Jasper, John C. 




Arlington Heights, Illinois 60004 (US) 


(30) Priority: 25.10.1996 US 740298 


• Feigen, Jerry S. 




Chicago, Illinois 60657 (US) 


(71) Applicant: Navigation Technologies Corporation 


• Bouzide, Paul M. 


Rosemont, Illinois 60018 (US) 


Chicago, Illinois 60034 (US) 




• Fernekes, Robert P. 


(72) Inventors: 


Wooddale, Illinois 60191 (US) 


• Ashby, Richard A. 




Hebron, Illinois 60034 (US) 


(74) Representative: 


• Israni, Vijay S. 


McLeish, Nicholas Alistair Maxwell et al 


Hoffman Estates, Illinois 60195 (US) 


Boult Wade Tennant 


• Lampert, David S. 


27 Furnival Street 


Highland Park, Illinois 60035 (US) 


London EC4A 1PQ(GB) 



(54) Interface layer for navigation system 



CM 
< 

I s - 

00 
CO 
CO 

o 

LU 



(57) An improved method and system that provides 
for a data access interface layer in a navigation system. 
The navigation system is of the type that includes a nav- 
igation application software program that provides nav- 
igating features to a user of the system and a geographic 
database stored on a computer-readable storage medi- 
um wherein the geographical database includes infor- 
mation relating to the geographical region about which 
the navigation system provides the navigation features 
to the user. The data access interface layer is preferably 
stored in the navigation system as a library of software 
functions. The data access interface layer operates in 
conjunction with the navigation system application soft- 
ware. The data access interface layer isolates the nav- 
igation application software from the geographic data 
which are stored on the storage medium. The data ac- 
cess interface layer intercepts requests by the naviga- 
tion application software for geographic data. The data 
access interface layer retrieves geographic data from 
the storage medium and converts the data into a format 
usable by the navigation application software. The data 
access interface layer also provides for memory man- 
agement that facilitates accessing and using geograph- 
ic data from the particular storage medium quickly and 
efficiently. By recognizing that different media types 
have different physical formats, the data access inter- 



face layer accommodates and isolates the differences 
so that the portions of the data access interface layer 
that interact with the navigation application software can 
be generic. 

FIG. 2 
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Description 

REFERENCE TO RELATF H APPLICATIONS 

rated by reference herein. 
W BACKGROUN D THF INVENTION 

geographic areas or regions^ , a , navjjj or ]^™^J^%Z?T*» deLed geographic data set 
microprocessor, memory, and storage, and, optionally, W c p "ni7i»d data files or databases. The detailed 

g==s^ 

are well-known in the art. nfl „ iri fltion svstem is a software program that uses the detailed 

— ™ n — ph,c area 

^^r^TS-*- - nation app.icat ,on ^^S^ t^X^- 

positioning system into a single unit, 

Alternatively, navigation application programs and geographic ti la asete .may oe p > navjga t io n system may 

sold or licensed to users to load in their own persona computers. In fu rthe atternatively, on-.ine via 

be centrally or regionally located and accessible to multiple * -er^n - » "^^^^ or * ay utilize a 
a network or communications link. Personal computer-based systems may »s tend ato y ^ 
communication link to a central or regional or disputed system. A.sa users ma ^««a ™ ? r0 digy, and America 

reT?:^^^ 

iga.ion „.« is mat there are numerous ditferent nation system ^™ S e ,^^™™^ d y eve)oped Me - 
hardware. navigation sot.ware, operating systamjand so on Many o nhes, %£T£ZZ> geographic data and 
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databases that can be used with the various different types of navigation system platforms due to the numerous different 
platforms that exist. This problem may be exacerbated in the future as navigation system manufacturers develop new 
generations of navigation systems with more and enhanced features. 

Another problem exists with regard to providing updated geographic data for existing navigation systems. Just like 
5 conventional printed maps, geographic information used in computer-based navigation systems can become out-of- 
date. For example, new roads are built, businesses change locations, road construction closes roads, detours are 
established, museum and restaurant hours change, etc. It is expected that end-users, such as vehicle owners who 
have navigation systems in their vehicles, will want to have the geographic data in their navigation systems updated 
from time to time. 

10 The proliferation of multiple, different, incompatible navigation system platforms, mentioned above, also presents 

an obstacle to providing updated geographic data for end-users, i.e. the persons and businesses who own and use 
navigation systems. In order to provide updated geographic data for an end- user's navigation system over the lifetime 
of the navigation system, the provider of geographic data needs to provide a product that not only has updated geo- 
graphic data, but also that is compatible with the user's particular navigation system. Over the expected lifetime of 

'5 navigation systems, which may be ten years or more, this would require supporting a growing number of old, incom- 
patible navigation systems and platforms. If specialized versions of updated geographic data products had to be pro- 
duced for each separate, different type or version of navigation platform the number of different products would continue 
to increase over time thereby making the provision of updated geographic data products to end-users difficult and 
expensive. 

20 Accordingly, it is an object of the present invention to provide a solution to the problem of providing geographic 

data for a variety of hardware platforms. 

Further, it is an object of the present invention to provide an improved navigation system and geographic navigation 
database(s) for use therein, that can be efficiently developed; manufactured, customized, distributed, and/or updated 
across a variety of navigation system platforms, operating systems, and releases. 

25 

SUMMARY OF THE INVENTION 



To achieve the foregoing and other objectives and in accordance with the purposes of the present invention, there 
is provided an improved method and system for a data access interface layer in a navigation system. The navigation 

oo system is of the type that includes a navigation application software program that provides navigating features to a 
user of the system and a geographic database stored on a computer-readable storage medium wherein the geograph- 
ical database includes information relating to the geographical region about which the navigation system provides the 
navigating features to the user. The data access interface layer is preferably stored in the navigation system as a library 
of software functions. The data access interface layer operates in conjunction with the navigation system application 

35 software. The data access interface layer isolates the navigation application software from the geographic data which 
are stored on the storage medium. The data access interface layer intercepts requests by the navigation application 
software for geographic data. The data access interface layer retrieves geographic data from the storage medium and 
converts the data into a format usable by the navigation application software The data access interface layer also 
provides for memory management that facilitates accessing and using geographic data from the particular storage 

•*o medium quickly and efficiently. By recognizing that different media types have different physical formats, the data 
access interface layer accommodates and isolates the differences so that the portions of the data access interface 
layer that interact with the navigation application software can be generic. 

BRIEF DESCRIPTION OF THE DRAWINGS 

45 

FIG. 1 is a diagram illustrating a navigation system including a storage medium upon which geographical data, 
and optionally other data, are stored. 

FIG. 2 is diagram illustrating the software components in the navigation system of FIG. 1. 

FIG. 3 is a block diagram illustrating the software components of the navigation system of FIG. 1 including the 
50 major systems of the interface layer of FIG. 2. 

FIG. 4 is a block diagram illustrating one embodiment of the resource manager software architecture of FIG. 3. 
FIGS. 5A and 5B are illustrations representing memory storage during operation of the cursor management system 
shown in FIG. 3. 

FIG. 6 is an example illustrating a parcel ID used in the physical address storage mapper of FIG. 4. 
55 FIG. 7 is a flow diagram illustrating the process for linking the navigation application component with the data 

interface layer. 

FIG. 8 is a block diagram illustrating another embodiment of the resource manager software architecture of FIG. 3. 
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nPTAII FD DESCRIPTION OF THE PP PSFNTI Y PREFERRFP EMBODIMENTS 
I Ov rvi w of navigation system 

is loaded from the ROM 16 into a memory 20 associated with he processor ^ ; cessors using a fla , 

system. The processor 12 may be^ 

address space, such as a m **l*™-™^\^^ t han these , as well as processors that may be developed 
similar or greater addressing space). Processor types othe than ™? J present embodiment, the storage 

^^^iSM^ ^"uSE AND STORAGE O, OEO- 

tne art. The poeittoning system 24 outputs a ^^^^^ , ^^ ci , etc., o, the navigation 
application software 1 8 that is run on the processor 1 2 to 'determine , the locatio , ^ P 

200 of the navigation application program 18. The organization and f ^e o g g ^ P METHOD FOR USE 
in more detail in the above referenced copending application entitled IMPROVED SYSTtM 

lions of the geographic data 4U irom me bio y interface layer 41 is located between the various 

o, the navigation ^^^^^^^^^J^ datase, 40. The data access 

end-user's navigation system. 
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II. Data acc ss int rface lay r - overvi w 

The data access interface layer 41 is a software component that may reside in the navigation system 10. In a 
preferred embodiment, at least a portion of the data access interface layer 41 is linked or compiled into the executable 
5 module that forms the navigation application software 18 in the navigation system 10 that is loaded into the memory 
20 (FIG. 1) from the ROM 16 when the navigation system 10 is operated. Within the data access interface layer 41 
there are several subsystem components. There are internal interfaces between these subsystem components and 
external interfaces to the navigation application software components 200 and operating system 202 of the navigation 
system 10. Data are presented to the navigation applications as logical data entities. The logical data model entity 
10 records are fixed length and contain decompressed data without any of cross-reference information. 

In a preferred embodiment, the data access interface layer 41 is provided in the form of a library of software 
functions. This library of functions provides data access for use by the various components or subprograms 200 of the 
navigation application software program 18. In one preferred embodiment, some or all of these library functions are 
directly linked to the various navigation applications 200 to form the navigation software product 18. Thus, the data 

15 access interface layer 41 is incorporated into the navigation application software of the navigation systems of OEM's 
(original equipment manufacturers) or aftermarket automotive navigation systems, which use a separately stored ge- 
ographic database. In alternative embodiments, discussed below, the data access interface layer 41 may be incorpo- 
rated into other-than-in-vehicle navigation systems. 

In a preferred embodiment, the source code is written in the C programming language, although in alternate em- 

20 bodiments, other languages may be used. 

Because the data access interface layer 41 is used with various different navigation systems, the interface layer 
41 takes into account differences among these systems. Some in-vehicle navigation systems have relatively small 
quantities of RAM, slow I/O devices, and proprietary and/or real-time-oriented operating system kernels. Some of these 
navigation systems calculate an optimal route and provide real-time, turn -by-turn guidance to the end-user. Accordingly, 

25 jt is advantageous to integrate various position and heading sensor information in real-time and in the background. 
Some of these navigation systems also provide cartographic display a flexible capability to obtain route destination 
points, and an interface oriented to in-vehicle ergonomics. 

As mentioned above, the data access interface layer 41 isolates the navigation application software 18 from the 
size, complexity, and evolution of the geographic map database 40 on the physical medium 22. In a preferred embod- 

oo iment, similar or identical data access interlace layers can used by different navigation systems. The data access 
interface layer 41 is portable across different hardware platforms. The data access interface layer 41 provides versatility 
to support most or all envisioned navigation application functionality for a wide range of product capabilities and hard- 
ware platforms. In a preferred embodiment, the software library that comprises the data access interface layer uses 
less than 256 K bytes of memory and 16 Kbytes of stack memory, and at least 256 Kbytes of heap memory. 

35 As mentioned above, the geographic data 40 is stored on the storage device 22, such as a CD-ROM. In a preferred 

embodiment, the geographic data is stored using some or all of the physical storage format features disclosed in the 
above referenced copending application entitled "IMPROVED SYSTEM AND METHOD FOR USE AND STORAGE 
OF GEOGRAPHIC DATA IN PHYSICAL MEDIA." The features used in the physical storage format provide for efficient 
access to the geographic data and associated third party data ("TPD"). Different types of storage media have distinct 

40 data capacities and access characteristics. Accordingly the physical storage format features disclosed in the copending 
application account for the various media intended for use in navigation systems. Although the present embodiment, 
of the data access interface layer 41 uses the physical storage format disclosed in the copending application, some 
or all of the features of the data access interface layer disclosed herein may be used with other formats. 

As described in the copending application, the geographic data are stored on the medium by means of a geographic - 

45 dataset compiler. The compiler accepts geographic data and associated third party data in an interchange format. The 
geographic data and third party data are input to the compiler which generates an output in the form of an appropriate 
physical storage format. The geographic data may be published by Navigation Technologies of Sunnyvale, California. 

FIG. 3 is a block diagram of the navigation system 10 showing components of the data access interface layer 41 . 
In FIG. 3, the data access interface layer 41 is shown in the navigation application software 18 logically below the 

50 navigation application programs 200 and above the operating system 202. This allows the data access interface layer 
41 to be responsive to data access requests from the various navigation application software programs 200. 

The software library that forms the data access interface layer 41 may be regarded as being composed of three 
major subsystems. The topmost subsystem is the data access programming interface query logic ("DQL" or "query 
logic") subsystem 210. The query logic subsystem 210 provides a function call interface 212 to the navigation appli- 

55 cation software programs 200. The data access interface layer 41 defines a data structure view (referred to as the 
"Logical Data Model" or "LDM") of the geographic data 40 on the storage medium 22 to the navigation application 
programs 200. 

In a presently preferred embodiment, the data structure view defined by layer 41 is in the C-language. As mentioned 
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^ « iooica, da,a ™d.l repents ft. «i,i.s in lull, t^E^tlSE 
iom, a„ no, con,pac,ad. Mho** ,nis ,es*£ wa. ed^a-w » « ^^a »»«,. k no»n p,«e. 

component of the navigation application programs 200 subdivisions of the physical media, called 

The query .og.c subsystem 210 resolves data ^^^^ ^ on the medium 

"parcels", which contain the requested data ,n the physical storage format o g t ^ expressed in 

22. The query logic subsystem 210 also provides for "^^^^"1^^ Tea**** .hat allows the 
terms of a "cursor" for those queries that can J U J ^ e ^ e ^ rt ^^ uiring an in-memory copy o, . 
navigation application programs to access parts of a large query result 

each record in translated logical data model form. translation (I MM) subsystem 216. The 

index management and data translation suDsysiem ^.o h moHilim „„ direct ed bv the query logic subsystem 

index information to locate data for physica. enHt.es stored on ^^^^^^Z unpack or other- 
210 A second function provided by the index management and data ^ r ^ S ^^ del data en P titjes that are 

wise decompress the optimized entities and to transform ^ enm.es in on tne medium 

compatibility across different versions, as explained further below management-subsystem 220 

Below the index management and data translation «*>^J^^£^£^ the I/O bandwidth is 
As mentioned above, in some navigation systems, the For example, one 

relatively low. Conventional techniques for the ™ na 9*™^ 

SCM«^^ t may SET as we "' par " 

Sr^here'muUipJuncLs o, the navigation ^f^^^^^^^l^ embodi- 
An improved approach to resource management is provided by the present embod meru ir ' P , a 
menMhe d'ataacceTs interface .ayer41 is provided witr uts own ^^^^^^^^ 
from any resource management function provided by the 7' , ^^^^^ i ^ inaged by , he resource 
is provided with a portion of the navigation system memory for '^^^S ^ SaMity to use additional 
management subsystem 220. .n addition, the resource ^^^^^^J^. The resource 
portions of navigation system memory when they are ,not needed I by l ^"™*Tan7uoly focussing on data access 
management subsystem 220 provides for .mproved management * ™ m ^^ '^ tjon of t he 9 pnysiC al storage 
requirements of the query logic subsystem taking into ^^^Z^^^^ and the physical I/O 
format. The resource management subsystem 220 mediates access l ° ^= he ^ m ^°^ of acti0 nsand data 
channel for data access tasks. Management of these resources a.s benef its programs 
needs above the level of the data access interface layer 41 , use d to h^'P determine which data to 

200. The data access needs of the navigation appl.ee ion ^^f^ Ztsouce management subsystem 

III. Query Logic (DQL) Subsystem 210 

,ay e r 41 TKe queiy logic .utay.ttm 210 mp.emanis an interf ace 2 Mo the ^nay.oauon app £ ^ 
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embodiment of the data interface layer 41 is defined as C-language structures, the interface layer could be defined in 
any suitable programming language). In a preferred embodiment, each of the data access interface layer function calls 
made by the navigation application programs is implemented as a wrapper around a corresponding function call in the 
query logic subsystem 210. 

5 In general, the query logic subsystem 210 provides three kinds of data access capability to the navigation appli- 

cation programs. One kind of data access provided by the query logic subsystem allows the navigation application 
programs to request a particular data entity by its database identifier (DBID). The query logic system 210 provides the 
requested data entity to the navigation application in the logical data model format. Another kind of data access provided 
by the query logic subsystem 210 allows the navigation applications to request a set of data entities that are related 

10 to a particular data entity. The query logic subsystem provides the navigation application with a cursor (explained in 
more detail below) to the resultant set of data entities. Some or all of the data entities in the resultant set may be in 
the logical data format. A third kind of data access provided by the query logic subsystem allows the navigation appli- 
cation to obtain data based upon a search request. The query logic subsystem returns a cursor to a resultant set of 
data entities that match the search criteria. 

is The functions that form the interface 212 allow the navigation application programs 200 to request a particular 

entity or a group of entities (such as "nodes", "places", "segments", "points of interest", "postal codes", and so on) 
which can be qualified by a particular subset of attributes (such as "all segments that have an end point at node X", 
or "all municipalities including the word "Lake" in name, and so on) which are either directly a part of or are otherwise 
closely associated with the entity Alternatively, these requests can also be qualified by geographical parameters or 

20 attributes, such as all segments within a specified rectangular area or inside a particular named place. The geographic 
qualifiers can be applied to the primary map data entities and can be useful for narrowing down a search for desired data. 

The functions in the query logic subsystem 210 provide for pervasive access to data. This means that access to 
any and all logical data model entities is supported with a reasonable level of performance regardless of navigation 
application intent. For example, the route guidance software 28 (FIG. 2) may require access to point-of-interest data. 

25 Support for pervasive access to data occurs regardless of the classification of entities that occurs at the physical storage 
format level to optimize data access performance to the base set of entities required for important functions such as 
route calculation or map display. Pervasive access to data offers some synergy with the geographic query qualifiers. 
For example, rectangular queries are commonplace for geometric data such as segments or nodes, but are also useful 
for street names and points-of-interest. 

30 The query logic subsystem 210 also includes the ability to initiate a data access transaction that is predictive in 

nature, e.g. where data are not required right away but are anticipated to be needed soon. This type of data access 
transaction preferably occurs in the background, allowing the navigation application programs to continue to perform 
work. As such, the query logic subsystem 210 provides the capability to make these predictive access calls in addition 
to normal access calls where the data are required immediately. This function coordinates with the navigation appli- 
es cation programs 200 to predict what data may be required next. 

Some of the query logic subsystem functions return a single entity or additional detail about a particular entity. 
However, others of the functions return an unpredictable number of entities. Depending on the particular query and 
the degree to which it is qualified, this number could potentially be quite large. For this reason, these query logic 
subsystem functions include a cursor management subsystem 249. A cursor is defined at the time of the query The 

io cursor forms a window (explained below) into an arbitrarily large result set built by the query. The cursor allows the 
navigation application to specify how many entities should be returned at a time when data are fetched through the 
cursor. General-purpose cursor management functions in the data access programming interface 212 allow the navi- 
gation application software programs 200 to subsequently move this window in a flexible and convenient manner. 

45 A. Query resolution 

The data query logic subsystem 210 implements the interface to the navigation application programs 200 by re- 
solving queries from the programs to a set of physical data subdivisions, called parcels, which exist on the media. 
These parcels may contain spatially-organized data, non-spatial data, index information, or other data. Once parcels 

50 are identified in response to a query, they are read into memory. The data within a parcel may be further organized 
into subsets to minimize the amount of data that need to be examined in a parcel to resolve a query. The appropriate 
parcels or parcel data subsets are identified and entities are located within those parcels or parcel data subsets in 
order for the data query logic subsystem 210 to build a cursor result set for a particular request. Alternatively, a single 
logical data record may be returned directly to the navigation application software programs 200 for simpler queries 

55 which always return a single record and which do not require construction of a cursor. However, both of these ap- 
proaches locate and obtain one or more physical parcels, which ultimately reside in the physical storage format on the 
storage medium 22, and physically examine some subset of the parcel data to locate the entities that make up the 
result set. Once the result set is identified, the entities are transformed into the logical data model format and returned 
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to the navigation application software programs 200. „ hwQir3 , ., nraoe format used on the storage medium 

tem 242 and the physical-to-logical data translation subsystem ,244. ^ 

At least two approaches are used to rn.nirn.ze accesses to the phys^al med^m^O pp 
information within parcels to look up data. Another approach « ^ u« ^e^D b y y 

Cuncian fo ,nav,gaUng ,he Index on the pnys.ea! medium " into a lorn, amenable lo. 

dependent services provided by the index management and ™^™*^*™~* nw - K an d independent o. 
subsystem 244. This allows the '"*e"™«^ to obla P jn parcels 

the physical storage format. The query resolution process a Iso mak «? use o< ° w jhese services are provided 
fromVe physica. medium or cache memory and to ob,^^^ 

and navigation subsystem 242 and the ^^^^^^^ 242 takes an index specifier and query 

One interface 248 in « 
parameters information from the data query logic suDsysie Dh vsical organization of the data in the 

I a format-specific construct for identifying the parcel that ,s related ^^^^ mana ^ tslA ^ Mjm 
physical storage format on the medium. The parcel £ management and navigation 

220 to obtain a pointer to the physical parcel in ^W^"^^^^™ nd * application program 

subsystem 242 provides for ^^^^^S^T^^^^ «W?o further resolve 

^oT P =^ 

fndexTor 2e parcel data sublets) to locate the ^^^ce^ — record^ ^ ^ 

When internal index information is no. present to resolve a query o a pa Ucul .r en y 
parcel, a brute-force record Inspection or binary ^ ^"f^ ^ i a^ decompressed inLidiL 

lypes of media. In a preferred embodiment the inter mediate , torm ai £ , cljent of 

level of the physical format. This independence allows ^^^^^ l^^ to reso fve queries. The 
.he physical-to-logica, subsystem 244, to examine Z^-Ze^Zo^ons for conversion within 

decompressed intermediate format conversion interface ,s prima Jy e cord basea, w.t p te 
parce. subdivisions, if necessary. The conversion f^^^ 1 ^^^^^ specification levels, 
the translation to the decompressed intermediate forma. t ^^*^^^^ nd £ maintain records 
The decompressed intermediate forma. ^^^^^^^^Ln in the corresponding 
in full logical data model format. Entities ,n ^^^^^SSL that are known to the application 
decompressed intermediate format Logical data ^1™ M »*™™™J^™ De)errlnq conversion from interme- 
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the same parcel. The amount of memory required to hold the data in this intermediate format is preferably smaller than 
the amount of data that would be necessary to hold the same data entities in the logical data model format. Finally, 
when entities that comprise the result set have been identified by the query resolution logic, another physical-to-logical 
interface 255 is available to translate the data to the logical data model format for return to the navigation application 
s programs 200. 

B. Cursor management 

The query result from the data access interface layer 41 is copied into memory buffers provided by the navigation 
10 application software programs 200 regardless of whether or not cursors are involved. This allows the data access 
interface layer 41 to compress (i.e. compact) the memory allocated to it in its memory pool without affecting the navi- 
gation application programs 200. The cursor management subsystem 249, mentioned above, is part of the query logic 
subsystem 210. When a cursor-based query call is invoked in the data access interface layer 41 , an internal cursor is 
constructed by the cursor management subsystem 249 and a unique reference to the cursor is returned to the one of 
15 the navigation application programs 200 that requested the data. The cursor reference is used to obtain all or some 
portion of the resulting data. When data are obtained via a cursor, the navigation application program 200 specifies a 
memory buffer in a size that is a multiple of the returned logical data model entity size. This multiple is based on how 
many records at a time the navigation application program prefers to (or can afford to) handle at one time. In a preferred 
embodiment, this technique is facilitated because the logical data model entities are of a known fixed size. 
20 The cursor management subsystem 249 stores the entities that comprise the cursor result set in two different 

ways. Referring to FIG. 5A, some of the entities in the result set are saved in fully-translated logical data model form. 
Whether or not all entities in the set are maintained in the logical data model form depends on the number of entities 
that make up the query result set. For cases in which the result set size is below a first threshold, the entire set is 
maintained as an array 511 of decompressed logical data model entities. For cursors whose results set exceeds this 
25 first threshold, the remaining are maintained in a second array 513 that includes only entity identifiers. The entity 
identifier (which in many cases may be the database identifier, or "DBID") allows the record in the physical parcel to 
be quickly accessed for transformation into the logical data model format. 

The memory used to maintain the cursor result set is dynamically allocated using the internal private dynamic 
memory management interface provided by the resource management subsystem 220, as explained further below. 
30 When very large result sets are encountered, a partial result set may be maintained if the number of entities satisfying 
the query exceeds yet another threshold. This second threshold is provided to minimize any possible adverse memory 
impact of a very large result set. Each of these thresholds may be configured at the time that the executable module 
18 including the navigation application programs 200 and the data access interface layer 41 are compiled. The full or 
partial nature of a particular query is reported to the calling navigation application program 200 so that the number of 
35 records returned by the query can be properly interpreted. 

When a partial result set is maintained for a reference cursor, the query resolution process temporarily comes to 
a halt once the maximum partial query limit is encountered. In order to continue the query at a later time, the cursor 
also maintains enough information to resume the query resolution process at the point it left off. 

The cursor management subsystem 249 provides additional cursor functionality. Once a cursor is defined for a 
*o particular query, the cursor is positioned at the beginning of the result set. A "fetch next" cursor function fills the result 
buffer of the navigation application (specified in the query call which established the cursor) with the next N records 
and positions the cursor after the last record returned. The cursor is maintained as a "window" of logical data model 
records that moves across the result set, so that the cursor fetch process is simply a memory-to-memory copy from 
the cursor's address space internal to the data access interface layer 41 to the address space of the navigation appli- 
es cation program 200. 

Various forms of cursor manipulation functions are also provided by the cursor management subsystem 249 in- 
cluding the ability to reset the cursor position to the beginning, end, or an absolute position in the result set. A "get 
previous' cursor function is also provided to augment the "get next" functionality The absolute positioning function is 
useful in the context of the result set record count returned by the query function which establishes the cursor. 



50 



IV. Index management and navigation (IMIM) subsystem 242 



Referring again to FIG. 3, the index management and navigation subsystem 242 contains a portion of the physical 
format-specific index management and navigation software in the software library that forms the data access interface 
55 layer 41 . The index management and navigation subsystem 242 allows the query logic subsystem 210 and the resource 
management subsystem 220, above and below the index management and navigation subsystem 242, respectively, 
to be independent of the physical storage format used on the medium. 

Index information is used to resolve the location of a parcel which contains a desired entity or entities based on 
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efficiency. 

Once the data query logic subsystem 210 identifies an entity to be returned to the navigation application program 
200. it uses an interface 263 in the physical-to-logical subsystem 242 that translates the entity from the decompressed 
intermediate form to the final logical data model form. For non-cursor single-entity queries, the calling navigation ap- 
s plication program 200 supplies the memory buffer which holds the translated logical data model output. Otherwise, a 
dynamically-allocated private cursor memory buffer is supplied by the data query logic subsystem 210. Unlike the table- 
driven metatranslation process, the logical data model translation is coded into the physical-to-logical software imple- 
mentation. 

It may be desired for entities in the decompressed intermediate form to persist within or even across data access 
10 calls for subsequent repeated access. This could minimize the CPU overhead required to repeatedly perform decom- 
pression and metatranslation on the same data as well as minimize the memory management overhead involved with 
otherwise repeatedly allocating an output buffer. The management of this persistence is provided by the data query 
logic subsystem 210. This approach takes the anticipated CPU and memory savings into account, along with exami- 
nation of data access patterns to determine how often repeated access to the same decompressed data occurs. The 
is overall performance of the metatranslation process is also a factor in this analysis. 

In an alternative embodiment, some data entities may undergo direct transformation from the physical storage 
format into the logical data model format without intermediate translation into the decompressed intermediate format. 

Metatranslation describes the translation of data from the compressed physical storage format representation at 
some particular data version level (also referred to as a "specification level") to the intermediate decompressed rep- 
?o resentation known to the data query logic subsystem 210 at some other data version level. Metadata tables 259 are 
used to facilitate the transformation from one version level to another The physical storage format metadata tables 
259 are read off of the medium into semipermanently allocated memory at system initialization time. The metadata 
process is described more fully below. 



VI. Resource management (SRM) subsystem 220 

The resource management subsystem 220 provides access to memory and I/O resources for the software library 
that forms the data access interface layer 41. The resource management subsystem 220 manages the availability of 
navigation system memory and I/O resources for use by the data access interface layer 41 in a multi-tasking environ- 
ment in which the navigation application programs 200 also contend for these resources. In a preferred embodiment, 
the resource management subsystem 220 does not manage memory and I/O resources for the navigation application 
software programs 200 for tasks other than accessing the geographical database via the interface layer 41 . 

There are two primary data access interfaces to the resource management subsystem 220. The first allocates and 
frees workspace memory from a pool that is reserved exclusively for use by the data access interface layer 41. The 
second interface specifies a parcel identifier and returns a pointer to a cache memory buffer that contains the parcel. 
The priority of the parcel can be specified, i.e. an indication of how soon (relatively) the parcel is needed. This feature 
enables prioritization of parcel I/O transactions and persistence of parcel data in cache when cache is in contention. 
When a requested parcel is not found in cache, a physical I/O transaction is initiated to read the parcel off the medium. 
There are additional interfaces in the resource management subsystem 220 that are used to allow the navigation 
application software 200 to adjust the resource management strategies at run time. 

There are at least two approaches that the resource management subsystem 220 uses to increase performance. 
The first is to minimize and optimize I/O transactions within a constrained memory environment consisting of a portion 
of the navigation system's heap memory that is dedicated to the software library that forms the data access interface 
41. The second is to manage access to this relatively small portion of memory. Memory management also includes 
methods for maintaining data in cache buffers to minimize I/O and for compacting of the dedicated heap memory. 
These approaches are achieved with small amounts of CPU and memory overhead. In order to implement these ap- 
proaches, the physical organization of data on the storage medium, as well as the query optimization techniques 
implemented in the data query logic subsystem 210 and index management and navigation subsystem 242, is taken 
into account. 

This resource management subsystem 220 works across a wide variety of media types, physical storage formats, 
operating system environments, and device driver capabilities. A variety of mechanisms are provided to optimize the 
resource management subsystem 220 for a particular navigation system platform and navigation software application. 
These mechanisms include the setting of configuration parameters at compile time. Also included are a set of function 
calls in the data access interface layer 41 that influence resource management behavior at run time. Additionally, the 
calls for data access are designed to take advantage of built-in resource management capabilities such as background 
data access. Further, the resource management subsystem provides for prioritization of requests for multiple parcels 
when more than one parcel is requested by a function (i.e. function level granularity), and alternatively the resource 
management subsystem can even provide for prioritization of requests for multiple parcels even when parcels are 
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the I/O manager 270 to continue to process physical I/O ,n the ' ^Q-ound « f ^ 

This embodiment of the I/O manager 270 would be used in ^^^^ the l/Q manager 270 may 

capability. This alternative embodiment is described in more detail below. 
A. Memory Management 
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200 allocate its own private buffers to hold returned logical data model data entities. This isolation allows the resource 
management subsystem 220 to pursue compaction strategies to minimize fragmentation of the memory pool 278 with- 
out requiring the navigation application programs 200 to handle this memory management task. 

5 B. Cach managem nt 

Requests for data and index parcels are routed through the memory management library 280 in terms of a parcel 
identifier. A search for the parcel in cache memory is performed. A physical I/O request to the I/O manager 270 occurs 
when the parcel cannot be found in cache. Once the parcel is in cache memory, an interface 285 in the resource 

10 management subsystem 220 locks the parcel in the buffer when the buffer address is returned to the data query logic 
subsystem 210. This prevents the buffer from being swapped out when a data access interface call is active. An 
additional interface 279 of the resource management subsystem 220 releases this lock, and is called before the data 
access interface call returns control to the navigation application program. Swapping may occur when a large number 
of concurrent parcel requests causes the system to approach memory overcommitment. 

is The persistence strategy for the cached parcels is also implemented in the memory management library 280. This 

strategy takes buffer locks, priority, usage history, and usage counts into account in order to determine which buffers 
should be swapped out. 

The navigation application software program 200 is in position to anticipate what data may be needed eventually 
versus what data are required immediately. In order to differentiate data access requests between immediately required 

20 data and data to prepare for subsequent access, the resource management subsystem 220 supports synchronous (i. 
e., waits for result in the foreground) and asynchronous (i.e., processing continues while I/O proceeds in the back- 
ground) parcel requests. The asynchronous calls are used by "cache prepare 1 ' data access interface functions. An 
asynchronous request allows the navigation application program 200 to continue doing useful work while the I/O trans- 
action proceeds in the background. An interface call 281 in the resource management subsystem 220 is also provided 

25 to allow the navigation application program 200 to cancel a asynchronous data request. In addition, a resource priority 
value is provided in each data access interface call to give even finer control to the navigation application program 200 
to manage these foreground and background requests. 

C. I/O manager 270 

30 

In the embodiment shown in FIG. 4, the I/O manager 270 receives requests for physical I/O. These I/O requests 
originate with the synchronous and asynchronous "request parcel" interfaces 287 provided by the resource manage- 
ment subsystem 220 whenever the requested parcel cannot be found in cache memory. When this occurs, the memory 
management library 280 initiates an I/O request via the I/O manager interface 269 which results in an I/O transaction 

25 request being put into .an I/O manager message queue. The I/O manager interface 269 is depicted in FIG. 4 in the 
statically-linked portion 271 of the resource management subsystem 220. In this case, contention to the I/O queue is 
managed using interprocess communication techniques such as message queues 273 connecting the I/O manager 
interface 269 to the separate I/O manager process 270. The message queues 273 provide a single point of event 
notification for each process (i.e. client). The message queues 273 may be used for notification of events, including I/ 

-*o O completion, memory allocation completion, or resource access allowance. Other events may also be supported. 
There is one client message queue for each process (i.e;, client). 

In a preferred embodiment, I/O transactions arriving via the queue 273 are received in terms of parcel identifiers. 
Also included may be an indication of the priority of the request, an identification of the task (client) making the request, 
an indication of a message queue used by the originator of the request. By using parcel identifiers, the memory man- 

JS agement library 280 and the I/O manager 270 can remain independent of the physical storage format. Dependencies 
on the physical storage format in the resource management subsystem 220 are discussed below. Translation from 
parcel identifier to physical media address occurs for these I/O requests. When the I/O transaction is dispatched to 
the media device, the I/O manager 270 requests a cache buffer from the memory management library 280 to hold the 
data to be read from the media. This reduces interprocess communication overhead by preventing cancelled requests 

so from needlessly requesting and releasing a buffer, and minimizes cache contention by allocating the buffer at the latest 
possible time. 

There are two functions that the I/O manager 270 provides to enhance system performance. One function already 
mentioned is to allow physical I/O to occur in parallel with other activities. This allows other navigation application 
software functions 200 or data access interface layer software 41 to continue to run while a physical I/O transaction is 
55 jn progress. The other function provided by the I/O manager 270 is a serialization function that allows incoming I/O 
requests to be reordered. This reordering is based on several factors, including the priority of the request, the physical 
location of the data on the media, the current read head position. Other factors may also be included. Note that even 
within a single transaction submitted by a single navigation application process, multiple parcels may be specified. 
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\ * ^ /cnM\ oQP iwiPriia device isolation is provided by a media device isolation layer (MUIL) Juu. 

GC ( 7a '^^^^^T^r 270 h'andies a/data read from the medium. Under certain c^m- 
sJl ZZX^c*™ may access the data on the medium directly. For example, there ,s a spe^.c type 
o Third oar^da a s ored I on the medium, it may be preferable for the navigation appl,cat,on to access it directly. In 
^n ^To^yZ of data may benefit from being read direcUy from the medium or bypassing storage ,n 
cache Thes^ types of data include sound or video data. Due to the way these types of data are used, it may be 
preferable £ sound or video data to bypass cache storage and stream directly to the navigation application for pres- 
entation to the end-user.) 

D. File directory mapper 298 

The geographic database 40 exists in one or more physical binary files on the storage medium ,22 The parcel 

the startina location of the file is determined. Th,s information is provided by file directory mapper (FDM) 298- A tMe 
d^ec o rexistsTsome known location on the medium. This directory provides a physical media address or each c , 
fhe Ss on the * ed ° um regardless of whether they are geographic files or not. This file direct ory is specif, e d for he 
Z^J^LmZa Pr eLe6 embodiment, the ISO-9660 standard fi.esystem for CD-ROM media is used, although 
ofhe at r^Sle systems may a,so be suitabie. For read/write media, a DOS FAT niesy^.ay^ 

aoolication software 200, so that the locations of third party or navigation application-specif-c files f any, can be ob 
^ITlZstteZce allows the navigation application to implement a file I/O framework based on file descriptors and 
Ste offers so 2 third pall; or naliga.Japp.ication-spec.fic files can be accessed via the media device dnver 

intS ThTfile directory mapper 298 is able to ascertain the location of the file directory on the medium 22 based upon 
a predete JZ^oZiL of its structure. When invoked, the file directory mapper 298 reads the directory 'from he 
InZn ZZTon the medium. This is illustrated by the interface 301 between the file directory mapper 298 and the 
med^a devSe 22 A private buffer obtained from the memory management library 280 is used to hold a temporary copy 
of m >TeZn until he offset is determined. This activity takes place at initialization time for all geographic data Mes 
to ! repealed access of the directory. The starting location for each file is retained within the hie directory 

so mapper 298 for the duration of an operating session. 

E. Physical storage format address mapper 296 

As mentioned above the physical storage format address mapper 296 translates a parcel identifier (i.e^a "parcel 
ss , D -> ^TS^^tSL (or addresses) relative to the beginning of the file the parcel is located ,n. More 
Ze^Xt^T^ forma, address mapper 296 translates a parcel ID to a physical sector address and 
seSor coun t on me medium by us,ng the file address mapper 298 to locate the file on the medium and translating the 
Dating physical sector and sector count. Multiple addresses are returned for redundantly placed 
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index and data parcels. The address mapper 296 is a component of the I/O manager subsystem 270 that does not 
physically interact with the medium 22. 

The parcel identifiers are closely related to the physical addresses of the parcel on the medium. The identifier also 
carriers information about parcel size and a bit (or other information) which indicates the presence of redundant copies 

$ of the parcel on the medium. An example of a parcel ID 600 is illustrated in FIG. 6. The parcel ID 600 may consist of 
one part 601 that is an offset from the start of the file containing the parcel, a second part 602 that indicates the size 
of the parcel, and a third part 603 that indicates whether there are redundant copies of the parcel on the medium. The 
locations of redundant copies of the parcel are determined by use of a table which is retained in global memory through- 
out an operating session of the navigation system. This information can be combined algorithmically within the physical 

10 storage format address mapper 296 in a physical storage format-specific way to generate the physical address using 
minimal CPU or memory table overhead. 

The physical media address (or addresses for redundantly stored parcels) returned by the physical storage format . 
address mapper 296 is not a byte address, but is instead at a physical subdivision of the medium. For CD-ROM media, 
this subdivision is the 2 Kbyte sector For read/write media, the subdivision may be a smaller size such as 256. Similarly. 

75 the parcel size may also be expressed in these terms. 

The interface to the physical storage format address mapper 296 takes a parcel identifier (parcel ID) and returns 
a relative physical media address (or a set of physical media addresses for redundantly stored parcels) along with the 
parcel size. This information corresponds to the portions 601 and 602, respectively, of the parcel ID. The relative 
physical media address (or addresses) is added to an absolute file starting location address that has been obtained 

20 from the file directory mapper 298 at initialization time to produce an absolute physical address (or addresses) for the 
parcel. If redundant copies of parcel are provided, the I/O manager 270 then chooses the closest address based'on 
current read head location, and passes this address, the parcel extent (size), and the address of the cache buffer 
obtained from the memory management library 280 to the media device isolation layer 300 to initiate the physical I/O. 

25 R Operating system isolation layer (OSIL) 302 

An operating system isolation layer (OSIL) 302 provides an interface between the generic operating system serv- 
ices to which the data access interface layer 41 is written and the particular services provided by the operating system 
202 of the navigation system platform. For example, the operating system isolation layer 302 can be utilized to support 

oo various operating systems including ITRON, OS9, pSOS. VRTX, VxWorks, proprietary operating systems, and single 
task operating systems. The operating system isolation layer 302 is a software module that is related to a specific 
platform (or OS) and enables the data access interface layer 41 to operate on a particular platform. 

There are several different types of operating system services. The first consists of general purpose services, such 
as string functions (including transformation between multi-byte and wide-character formats), math functions, common 

35 utilities such as searching and sorting, and the like. The software library that comprises the data access interface layer 
. 41 uses some of these operating system services. For example, an ANSI C standard library (stdlib) interface is used 
for these functions. The memory management functions mailocQ and free() also fall under the stdlib interface. These 
are used by the resource management subsystem 220 to allocate and resize the memory pool 278 for internal man- 
agement (as mentioned above). 

•*o The other set of OS-level interfaces that the resource management subsystem 220 uses includes the protection 

of shared data structures in memory such as the memory management and cache control structures, and the I/O queue. 
Contention to these structures by multiple tasks linked to the data access interface layer 41 is managed using inter- 
process communication mechanisms such as semaphores and message queues. The resource management subsys- 
tem 220 preferably uses the standard POSIX.4 interfaces for these mechanisms. 

is jf another type of interface is provided by the operating system 202 of the navigation system 10, the operating, 

system isolation layer 302 implements the ANSI C stdiiband POSIX.4 interfaces as a translation layer to the interfaces 
for the native services provided by the navigation system OS. If it is not, then the service is implemented within the 
operating system isolation layer 302. 

Note that even though the resource management subsystem 220 uses logical POSIX.4 semaphore and message 

50 queue interfaces, this does not necessarily mean that a physical semaphore or message queue is used underneath. 
For example, it may be faster and/or easier, compared to using a physical semaphore, to simply disable interrupts 
while in a critical section of code, such as reading or updating a shared cache control structure, and reenable the 
interrupts afterward. In a preferred embodiment, use of interrupts is limited to actions that are predictably short in order 
to limit any impact on other tasks. Alternatively, the I/O queue can be implemented as a "semaphore-protected" shared 

55 memory buffer instead of a message queue when the I/O manager 270 is implemented completely within the statically- 
linked software library of the data access interface layer 41. This alternative embodiment is discussed below. A still 
further alternative is to provide a single interface layer task with no multi-tasking contention to these internal resource 
management structures whatsoever. 
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Deallocation and reallocation 

In a present embodiment, the interface layer advantageously provides for dynamic adjustment of the amount of 
memory used by the interface layer. This allows a portion of the memory in the navigation system to be used alternately 

s by either the interface layer or the navigation application programs depending upon which of these has the greater 
need for the memory. In a preferred embodiment, one or more of the additional blocks of memory over the minimum 
amount allocated by the interface layer may be subsequently returned to the navigation application when the navigation - 
application requires additional memory. According to this embodiment, during operation, the navigation application 
program 200 may request that an amount of memory be returned from the interface layer. The navigation application 

10 may require this additional memory for a memory intensive task, such as the display of a large number of items. Upon 
receiving the request, the memory manager 280 checks whether there is additional memory allocated to the interface 
layer in the memory pool 278 over the required minimum. If so, the memory manager 280 identifies an amount equal 
to one or more blocks, rounded up to the next higher whole block over the amount requested by the navigation system. 
(In a preferred embodiment, when allocating or deallocating memory from the navigation system, the memory manager 

>s 280 handles whole blocks.) By returning an amount rounded up to the next higher whole block over that amount that 
was requested by the navigation application, the interface layer assures that the navigation application receives at 
least the amount of memory it needs. The memory manager returns the memory to the navigation application by using 
a function call to the navigation system operating system, such as freeQ. 

Similarly, when the navigation application program no longer requires the additional memory, it can return the 

20 memory to the interface layer. Returning memory from the navigation application to the interface layer may follow a 
process similar to the initial memory allocation procedure, described above. In this manner, the interface layer can be 
assured of a minimum amount of memory for its own use, as well an additional amount of memory that it can routinely ^ 
use thereby providing a relatively high overall level of performance. Furthermore, when the navigation application has 
an intensive task, it can temporarily use some or all of the interface layer's memory allocation over the minimum amount. 

£5 This feature of the interface layer provides for an advantageous use of the resources of the navigation system by 
allowing for dynamic adjustment of the memory usage. 



Memory pool usage 

30 The memory manager 280 provides memory from the memory pool 278 for two different kinds of tasks. First, 

memory in the pool is used for a private workspace for the use of the interface layer subsystems. Second, memory in 
the pool is used for cache, i.e. to hold data read from the medium. When a parcel of data is read from the medium, it 
is stored in a cache buffer. The memory manager 280 keeps track of the number of available memory blocks in the 
memory pool and the number of blocks which may be allocated for private workspace. In some embodiments, newly 

35 allocated or freed blocks are preferably used for cache rather than for private workspace. 

The memory manager 280 allocates memory from the memory pool 278 for both cache and for private workspace 
in response to requests from tasks for buffers. A requested buffer may be smaller, larger, or the same size as one of 
the memory blocks in the memory pool. When attempting to satisfy a request for a memory buffer larger in size than 
the fixed memory block size, the memory manager attempts to locate a set of contiguous memory blocks that satisfy 

•*o the buffer size requested, and allocate these multiple contiguous blocks to service the request. Requests for memory 
may also be made for amounts less than the size of a whole block. The memory manager subdivides a memory block 
to satisfy smaller requests. Requests for smaller amounts of memory are more typically made for private workspace 
rather than for cache. 

Each allocated buffer, whether for cache or private workspace, is assigned a buffer ID. This buffer ID is a constant 
45 handle associated with the buffer over the lifetime of the buffer. Memory pointers to the buffer may change due to 
memory compaction. In a preferred embodiment, for buffers used for cache, the parcel ID is used as the buffer ID. For 
buffers used for internal workspace, a unique buffer identifier is generated. 



Task buffer counts and task buffer status 

The resource management system keeps track of each task's cache buffer count. A task's buffer count corresponds 
to how many buffers are "owned" by a task. Buffers are owned by a task whenever a task requests or reads data in a 
buffer or whenever a buffer is shared with another task that had ownership and the other task subsequently releases 
its ownership. If the buffer is used for cache, the data in the buffer include a parcel read from the medium and the 
ownership of the buffer is determined by the task that requested the parcel. When more than one task requests data 
in a buffer, the memory manager assigns ownership of the buffer to the last task that requested the data in the buffer 
or the last task that read data from the buffer. A task loses ownership of a buffer when another task takes ownership, 
of the buffer or when the task ignores the data (i.e. the parcel) in the buffer. A task also loses ownership of a buffer 
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data relating to certain geographic conditions or boundaries. The query logic subsystem 210 resolves the request into 
parcel ID'S by mapping the request to a set of parcels so that the data can be retrieved from the medium. This is done 
using the index management subsystem 242. Accordingly, it may necessary to first access the index data in order to 
identify the parcel ID's of the geographic data needed to respond to the query. Commonly-used index data may be 
s read into memory at initialization time. If the desired index data are not already in memory, they are read from the 
medium. 

Once the parcel ID of the desired data is identified, the request for the parcel is directed to the memory manager 
280. The memory manager examines the cache portion of the memory pool to determine whether the requested parcel 
has already been stored in cache memory in response to a request from a previous task. If the requested parcel is 
10 already in cache, the memory manager 280 returns a pointer to the cache buffer to the requesting task and locks the 
buffer (as explained above). If the requested parcel is not already in cache, the memory manager 280 sends the request 
to the I/O manager 270. In the I/O manager, the requested parcel is compared to a list of parcels that have already 
been requested but not yet been sent to the media driver. If the parcel is on the list of requested parcels, the task's 
(client's) identification is added to the information associated with the parcel. If the parcel is not in the list, the parcel 
15 is added to the list along with an identification of the task (client) requesting the parcel and information indicating the 
parcel's sector location and length. When a task requires a plurality of parcels, the listing of parcels are sent as a group 
to the I/O manager for retrieval in order to satisfy the request at the same time. 

For each parcel requested, the I/O manager 270 calls the physical address mapper 296. The physical address 
mapper 296 translates the parcel ID and returns the parcel size and physical starting sector (or sectors if the parcel is 
20 stored redundantly). Using this information, the I/O manager 270 sorts the I/O requests in priority and sector proximity 
order taking into account the current read head position. For parcels stored redundantly, the I/O manager 270 selects 
the sector that results in the minimum search time. 

The I/O manager 270 calls the memory manager 280 to allocate cache. The memory manager 280 scans a list of 
free memory in the memory pool 278 to find available memory and adds the available memory to cache. The memory 
25 manager 280 locks a buffer, as described above, to indicate that the memory associated with the buffer is reserved for 
I/O. Data are also stored that identifies the client task that requested the I/O. . - 

If the memory manager 280 finds no available memory, it attempts to swap out memory. As mentioned above, 
locked buffers are not swapped out. If there are any buffers whose status is "ignore", these are swapped out first. If 
memory is still needed in order to allocate cache for a new I/O, the list of tasks is examined to see if any tasks have 
oo exceeded their maximum buffer limit. If so, the memory manager 280 searches for any unlocked buffers used by the 
task and these are selected for swapping out. If memory is still needed for allocating to new data, buffers whose status 
is "active" are examined and these are swapped out for use for the new data. 

If the request for a memory buffer for the new I/O cannot be satisfied with the available memory in the memory 
pool 278, the memory manager 280 may perform compaction of the memory pool. As described above, only unlocked 
35 buffers are available for compaction. 

It may occur that even after compaction no memory is available in the size requested by the I/O manager for the 
new I/O. If this occurs, the memory manager 280 returns information to the I/O manager 270 indicating the largest 
cache space that is available. The I/O manager 270 then scans the I/O request list to determine whether any I/O request 
waiting to be serviced can be satisfied by the available cache. If there is an I/O request waiting to be serviced that can 
JO be satisfied with the available cache size in memory, this I/O request is serviced. The I/O manager 270 sends a message 
to the memory manager 280 to lock the cache memory that is available in the requested size. The I/O manager 270 
then sends the I/O request to the media driver for retrieval. 

If no I/O request in the I/O request list matches the available memory, the I/O manager 270 temporarily stops 
. generating new requests for cache to the memory manager 280. Eventually, as tasks are completed, the memory 
-*5 manager 280 unlocks or frees memory and as memory becomes available, the pending I/O requests are serviced. 

When the memory manager 280 indicates to the I/O manager 270 that cache is available to service an I/O request, 
the buffer is reserved. The I/O manager services the I/O request list by building scattered read requests. A number of 
reads may be chained together. Once this information is sent to the media driver, the I/O requests are removed from 
the I/O request list. 

50 The memory manager 280 sets the status of the cache buffer to "active." The memory manager returns a pointer 

to the buffer back to the task that requested the data, e.g. a call from the query logic subsystem. Once the pointer to 
the buffer is returned to the task that requested it. the buffer's status is set to "locked." The data in the cache buffer 
are used as appropriate. The pointer to the buffer is not changed until the task unlocks the buffer, e.g. by indicating 
that it has finished with the data in the buffer. When the data (in the logical data model format) are returned to the 

55 navigation application and therefore the data in the cache buffer are no longer needed by the task, the task in the query 
logic subsystem 210 also returns a message to the memory manager to reset the cache buffer from "locked" to "active" 
or "ignore" indicating that the data are not presently needed. When it is no longer "locked", the buffer may be compacted, 
moved or released. 
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,n genera, data are maintained in cache .or as .ong as possible consistent with.other J^may 
the advantage that once data are in memory they are stored in a cache because o. the , po "'W^ . 

which may be in cache, a task requests .he data by .he butter ID, which ,n a preferred emb^imen ^ TZeT The 

buffer itsetf are by offset and not absolute address as the base block address can move. 
Processing of a request for private workspace task 

As mentioned above, the memory manager 280 also allocates butters for private ^P^^~ e e ^ 

are locked while in use by the interface layer function. 
Operation of the physical-to-logical data translation subsystem 

The Dhvs.cal-to-loqical subsystem 244 subsystem is responsible for translation of information from the optimized 

logic system 210. 

Operation of cursor management system 

The tasks that request data as described above, may result in either small or large amounts of data being found.. 

wmmmmm 

sTze such as the DBID. Referring to FIG. 5A, this information is used to set up the arrays 511 and 513 for holdmg 
51 1 the da ta enti ty iu £ or ™ entitjes ^ gtored jn fu||y decompresse d form 
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cursor management system. 

In a preferred embodiment, the first array 511 supports both FIFO (first-in-first-out) and LIFO (last-in-first-out) 
during use of the.cursor cache. If a record beyond the last record in the array is requested, for example record 21 , that 
data entity is found (using the entity's DBID in the second array 513), decompressed into the logical data format, and 

5 stored in decompressed form in the first array 511 replacing the oldest record (e.g. record 1). Similarly, if record 22 is 
requested, it is found using the data entity ID from the second array 513, decompressed into logical data format, and 
stored replacing record 2 in the first array 511 . This type of access is in the forward direction and would use FIFO. On 
the other hand, if record 1 were then requested, record 1 would be retrieved, decompressed, and stored in decom- 
pressed form in the first array 511 replacing record 20. Record 20 would be replaced since it is the oldest record in the 

10 first array 511. This type of access is in the reverse direction and would use LIFO. 

Another example is shown in FIG. 5B. In FIG. 5B, the first array 511 is shown as being occupied with records 25 
through 44. If record 24*were requested, it would be decompressed and would be stored in the first array 511 replacing 
record 44. If record 23 were then requested, it would be decompressed and would be stored in the array 511 replacing 
record 44, and so on. 

is in FIGS. 5A and 5B, the second array 51 3 (i.e. the array that holds only the data entity ID's) is shown to have a 

size that accommodate only 1 00 data entity ID's. It is possible that the query will result in more than 100 entities. When 
there are more entity ID's than will fit into the second array 51 3, the cursor subsystem retains information that provides 
for one or more additional pages of data entity ID's. 

The following example illustrates the paging function of cursor system. For purpbses of this example, it is assumed 

20 that the first array 511 can hold 20 decompressed data entities and the second array 513 can hold 1 00 data entity ID's, 
but that the query results in 1000 records. 





Cursor Page 


ID's range in ID array 513 


ID'S range in cache array 511 


Page header 


25 


1 


1-100 


1-20 


1 




2 


80-180 


100-120 


80 




3 


160-260 


180-200 


160 




4 


240-340 


260-280 


240 


30 


5 


320-420 


340-360 


320 




6 


400-500 


420-440 


400 




7 


480-580 


500-520 


480 


35 


8 


560-660 


580-600 


560 




9 


640-740 


660-680 


• 640 




10 


720-820 


740-760 


720 




1 1 


800-900 


820-840 


800 


40 


12 


880-980 


900-920 


.880 




13 


960-100 


980-1000 


960 



In the example, initially the first array 511 includes records 80-100 in decompressed form and the second array 
513 is includes the first 100 data entity ID's, At this point, neither the first nor the second array includes any data entities 
or ID's beyond record 100. If the application want to access the 1 01th. record, the . query has to be resolved again. All 
the data entity ID's in the second array 513 are cleared and replaced with entity ID's for records 80-180. The record 
101 is decompressed and stored in the first array 511 replacing record 80. The table shows the ranges for each page 
when there are 1000 records and the arrays 511 and 513 hold 20 records and 100 entity ID's, respectively. 

The arrays described above can be used with various types of data including types of data that do not have their 
oven entity ID's. These types of data may be attributes associated with, or describe, entities in the database. Examples 
of these types of data include blocks, landmarks, and text. For these types of data, a virtual ID is assigned by the cursor 
management system. The virtual ID would be similar to a regular data entity ID except that instead of representing a 
type of entity, it would represent an offset, or other type of information. 

Certain types of data may not be handled by the cursor management system, but instead would bypass the cursor 
management system and be sent directly to the navigation application. These types of data may include shape points. 
The navigation application would provide appropriate memory buffers to accept the shape point information. 
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VIII. Porting and Configuration 

Fir 7 ia . (low chart showing a process lor compiling me source code lo, Ihe data access Menace layer and the 

„a»,iLTpSrs^ 

I y Po pre-inslajled in,o = ,orm ^^^'^~^SlT, numPe, o, runaPle paramelerc . 

WMMmmmm 

are used to optimize subsystem behavior at compile time. 
IX Updating and compatibility across version changes 

mmmmimm 
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manufacturer need not upgrade its navigation application software every time the geographic database is updated. In 
addition, the end-user who has an installed navigation system can acquire updated geographic databases over the 
years and be assured that they wilt work in his navigation system even if the updated geographic databases include 
new types of information. Because the geographic database publisher-distributor does not have to produce multiple 
5 different geographic database formats for a variety of different hardware platforms, the geographic databases can be 
made available to end-users at potentially lower costs, with fewer distribution complexities, and possibly more fre- 
quently, as well as with other advantages. 

If new attributes are added to the physical storage format, or if other changes to the physical storage format are 
implemented, the version level of the physical storage format may evolve beyond the version level of the navigation 

10 application program. Thus, when an updated geographic database is installed in a navigation system, it is possible for 
the logical data model format and physical storage format version levels to differ. As database version levels increase, 
as reflected in the physical storage format, forward compatibility is provided by means of the data access interface 
layer to maintain the viability of the end user's system. Forward compatibility can be supported in this manner for a 
long time, possibly up to ten years. Some data version changes may consist of adding new attributes or values, and 

is therefore one way that the data access interface layer can accommodate new attribute or values is to filter out the new 
data, reordering and transforming them to fit the old template. 

Compatibility across different version levels is provided by metatranslation. Metatranslation uses a set of tables 
for each version level. Referring to FIG. 3, these metadata tables 259 reside on the storage medium 22 (e.g. on the 
CD-ROM or PCMCIA card). The metadata tables include information that describes the location, size, type, and content 

20 of the various data attributes and values appearing in a given database entity. In the physical-to-logical data translation 
subsystem 244, conversion between the compressed physical storage format on the medium to the decompressed 
intermediate format usable by the query logic subsystem 210 utilizes a metadata table for each physical storage format 
data representation. The physical storage format metadata is used to extract a data element relative to the beginning 
of a particular physical storage format entity. The data element then undergoes a translation or conversion process 

25 which is controlled by the information in the metadata tables. 

Metadata tables may be located on the storage medium for each data version from the earliest version to a current 
version. The version level of the software library that forms the data access interface layer 41 is used to identify the 
appropriate set of metadata to use. 

The metadata tables are read from the storage medium through the operating system kernel and physical devices 

30 subsystem (i.e., the operation system isolation layer 302 and the media device isolation layer 300). From these sub- 
systems, the resource management subsystem 220 provides the metadata to the physical-to-logical data translation 
subsystem 244 where the metatranslation is performed. In a preferred embodiment, the metadata are physically read 
from the medium only at initialization time. The metadata tables are read into memory that is allocated from the heap 
on a semipermanent basis, so that the metatranslation process can access the tables efficiently for each data access. 

^5 Metadata tables can also be used to provide backward compatibility. Some navigation system developers may 

design their systems so that the navigation application software can be upgraded or updated over time after the nav- 
igation system is sold. This upgradability may be offered to take advantage of new features offered in the geographic 
database. In order to allow a newer navigation application software program to use an older version of a geographic 
database, a metadata table, for example table 813. can be provided in the new version of the navigation application 

JO software. Like the metadata table provided on the storage medium, the information in the metadata table provided with 
the newer version of navigation application software is used to compare the version levels of the navigation software 
and the physical storage format. The information in these metadata tables is provided to the physical-to-logical sub- 
system 244 at initialization time to perform any necessary attribute conversions. As mentioned above, if the version 
levels of the navigation application program and the physical storage format are the same, the metadata conversion 

45 step is unnecessary and the physical-to-logical subsystem can skip this conversion step. 

X. Further alternative embodiments 

The above embodiments disclose an interface layer system that can be used in a navigation system. In one present 
50 embodiment, the navigation system is an in-vehicle navigation system that is installed and located in an end-user's 
vehicle. The type of vehicle may include automobiles, trucks, buses, and so on. The end-users of such a system may 
include individuals who own or lease their own vehicles, as well as fleet owners, businesses, car rental agencies, 
trucking companies, transportation companies, and so on. In alternative embodiments, the navigation system may be 
other-than-in-vehicle. For example, the navigation system may be a hand-held unit that a person can carry on his/her 
55 person. Also, the navigation system may be installed in a non-mobile location, such as at a service station, car rental 
agency, a personal computer and so on. Still further the navigation system may be installed and used by traffic control 
agencies, police, delivery services, and so on. 

In a preferred embodiment, the interface layer is statically-linked to the navigation application programs after the 
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app.icat,on programs are compiled in order to form an execute module. ,n an alternative embod.ment, the interface 

layer may be dynamically linked to the "^^"/PP^Xmalive embodiment, asynchronous I/O is supported by 
An alternative embodiment is shown in FIG. 8. In this alternative emo °°>™ • » . (h , wnen a djsk , /0 is 
the navigation system's media device driver 609. ^"^^^^^^^J^Z^ request is 
submitted to the kerne,, the process invoking the ^« n ^^^^'^Je8t and return control 



described above. 
XI. Conclusion 



Na»i»a,ion .ysteo, develcpe-s can ,„.,e.o re locus o, , p.ov.d ^ in™ ^ 2S ir^.acc Rom ,h. end- 



Claims 
1. 



2. 
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product comprising an interface layer comprising. 

to said navigation application program in a logical data model format 

The invention of Claim 2 wherein said cursor providing means further comprises, 
tained in a compressed format. 
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4. The invention of Claim 3 wherein said cursor providing means further comprises: 

a fetch next function means adapted to provide a second portion of said cursor in said logical data model 
format, said second portion comprised of said first remainder. 

5 5. The invention of Claim 1 wherein said program code further comprises: 

means for managing indexes responsive to said means for accepting and processing requests and index 
information, said indexes managing means providing an identifier for obtaining geographic data on said physical 
storage medium for responding to said requests by said navigation application program. 

m io 6. The invention of Claim 5 wherein at least a portion of said index information is located on said storage medium, 
and wherein said indexes managing means provides parcel identifiers for obtaining pointers to parcels on said 
physical storage medium containing geographic data for responding to said requests by said navigation application 
program. 

is 7. The invention of Claim 5 wherein said indexes managing means further comprises: 

an interface for translating a specific entity identifier passed from said navigation application program to a 
parcel identifier for a parcel on said physical storage medium. 

8. The invention of Claim 5 wherein said index managing program code further comprises: 

20 an interface for taking an index specifierand query parameters from said means for accepting and processing 

requests and returning a set of parcel identifiers. 

9. The invention of Claim 5 further comprising: 

means for reading index information from said physical storage medium into a buffer, said indexes managing 
25 means coupled to said buffer to obtain said index information therefrom, 

10. The invention of Claim 1 wherein said translating means further comprises: 

means to unpack parcelized geographic data from said physical storage format into a decompressed inter- 
30 mediate format; and 

means to transform said geographic data from said decompressed intermediate format into data entities in 
said logical data format for returning to said navigation application program. 
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55 



11. The invention of Claim 1 wherein said means for transforming further comprises: 



a first interface for translation of geographic database entities from the physical storage format into a decom- 
pressed intermediate format; and 

a second interface for translation of geographic database entities from said decompressed intermediate format 
to the logical data model format in which said geographic data are provided to said means for accepting and 
4 o executing requests. 

. 12. The invention of Claim 11 wherein said means for transforming further comprises. 

a metatranslation means responsive to a metadata table on said physical storage medium and said first 
interface and adapted to translate said geographic data in said decompressed intermediate format at a first version 
45 level to a decompressed intermediate format at a second version level and provide said geographic data in said 

decompressed intermediate format at a second version level to said second interface. 

13. The invention of Claim 1 wherein said computer program product further comprises: 

50 means for managing resources comprising: 

means for allocating and freeing memory of said navigation system for use as a memory pool by said computer 
program product; and 

means for accessing a cache memory buffer in said memory pool that stores a parcel read from said physical 
storage medium, said parcel identified by means of a parcel identifier provided by an indexes managing means. 



14. The invention of Claim 13 wherein said resource managing means further comprises: 

means for initiating an I/O transaction from the physical storage medium to read said parcel therefrom if said 
cache memory buffer accessing means finds that said parcel is not stored in said cache memory buffer. 
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15. The invention of Claim 14 wherein said I/O initiating means further comprises: 

means for storing parcel identifiers in a queue: and 
means for reordering parcel identifiers while in. said queue. 

16 The invention of Claim 15 wherein said I/O initiating means further comprises: 

16. The trans|aling sa)d parce| jdentlfiers to a physiC al media address while ,n sa.d queue. 

17 The invention of Claim 15 wherein sa.d navigation system further .nc.udes a media dev.ce driver and wherein 
said physical read head position to said reordering means. 

means for executing query logic. 

19 The invention of Claim 13 wherein said means lor managing resources further comprises: 

means for resizing said memory poo, in response to a call from said navigation application program. 

prising: 

computer-readable program code for causing a computer to execute query logic for accepting requests for 

computer readable means for causing a computer to provide said geographic data to said natation applica- 
tion program in a generic ASCII format. 

21. The invention of Claim 20 wherein the physical storage format of the ^^^^ be UMd ° r9amZeS 
said geographic data into a plurality of parcels, and wherein sa,d invention further comprises. 

computer-readabfe program code means for causing a computer to associate said requests with parcels in 
c^2S££ : «£ tbr causmg a computer to read said parce, from said phys.ca, storage me- 
dium. 

22 The invention of Claim 20 wherein the physical storage medium comprises a CD-ROM. 

-S»523=SSS£S£3£= 

readable medium and comprising: 

a query logic program means for receiving requests from the navigation application program portion for geo- 

adaTa^ranltrmation program means for transforming geographic data from said physical storage 'or^M-nd 
a d a fa return pTogram means for providing said transformed geographic data to said navigation apphca.on 
program portion in response to said requests. 

24 The invention of Claim 23 wherein said interface layer further comprises: aciaole6 to 

an indexes management program means responsive to said query logic program means and adapted to. 

E=3Es=££S5S2S2=S 
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for transformation therein. 

25. The invention of Claim 24 wherein said indexes management program means further comprises means to obtain 
said parcel identifiers from said storage medium, and wherein said indexes management program means further 

s comprises means to obtain pointers to parcels on said physical storage medium containing geographic data for 

responding to said requests by said navigation application program portion. 

26. The invention of Claim 24 wherein said indexes management program means further comprises: 

program means for translating specific entity identifiers passed from said navigation application program 
10 portion to parcel identifiers for parcels on said physical storage medium. 

27. The invention of Claim 24 wherein said index managing program means further comprises: 

program means for taking index specifiers and query parameters from said query logic program means and 
returning a set of parcel identifiers. 

28. A method of using a computer-based navigation system wherein said navigation system includes navigation ap- 
plication program functions wherein said navigation application program functions are adapted to use a geographic 
database stored on a computer-readable medium in a physical storage format, the method comprising: 

20 accepting a request from one of said navigation application program functions for geographic data: 

using an index to identify a parcel in said physical storage format that includes the geographic data for re- 
sponding to said request; 

transforming geographic data stored in said physical storage format in said parcel into a format usable by said 
navigation application; and 

25 providing said transformed geographic data to said one of said navigation application program functions. 

29. The method of Claim 28 wherein said providing step further comprises: 

transforming said geographic data from said physical storage format into an intermediate decompressed for- 
30 mat; and 

transforming said geographic data from said intermediate decompressed format to said format usable by said 
navigation application program functions. 
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30. The method of Claim 28 further comprising the step of: 

prior to accepting a request from said navigation application, reading a metadata file from said storage medium: 
storing a portion of said metadata file in memory; and 

using said metadata file to translate from a version' level of said physical storage format to a version level of 
said navigation application program functions. 

31. The method of Claim 28 further comprising: 

after a plurality of data entities are identified in response to said request from said one of said navigation 
application program functions, providing a first partial result set of said plurality of data entities in said format usable 
by said navigation application program functions to said one of said navigation application program functions. . 



32. The method of Claim 31 further comprising the step of: 

if said plurality of data entities exceeds a first threshold, providing a first partial result set of said plurality of 
data entities up to said first threshold in said format usable by said navigation application program functions to 
said one of said navigation application program functions and maintaining entity identifiers for a portion of said 
50 plurality data entities exceeding said first threshold. 

33. The method of Claim 31 further comprising the step of: 

if said plurality of data entities exceeds a first threshold and a second threshold greater than said first thresh- 
old, providing a first partial result set of said plurality of data entities up to said first threshold in said format usable 
55 by said navigation application program to said one of said navigation application program functions, maintaining 

entity identifiers fora portion of said plurality data entities exceeding said first threshold, and maintaining a reference 
cursor to reexecute said request for geographic data for data entities exceeding said second threshold. 
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(57) An improved method and system that provides 
for a data access interface layer in a navigation system. 
The navigation system is of the type that includes a nav- 
igation application software program that provides nav- 
igating features to a user of the system and a geographic 
database stored on a computer-readable storage medi- 
um wherein the geographical database includes infor- 
mation relating to the geographical region about which 
the navigation system provides the navigation features 
to the user. The data access interface layer is preferably 
stored in the navigation system as a library of software 
functions. The data access interface layer operates in 
conjunction with the navigation system application soft- 
ware. The data access interface layer isolates the nav- 
igation application software from the geographic data 
which are stored on the storage medium. The data ac- 
cess interface layer intercepts requests by the naviga- 
tion application software for geographic data. The data 
access interface layer retrieves geographic data from 
the storage medium and converts the data into a format 
usable by the navigation application software. The data 
access interface layer also provides for memory man- 
agement that facilitates accessing and using geograph- 



ic data from the particular storage medium quickly and 
efficiently. By recognizing that different media types 
have different physical formats, the data access inter- 
face layer accommodates and isolates the differences 
so that the portions of the data access interface layer 
that interact with the navigation application software can 
be generic. 
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